1. Do you think it is important to articulate what we do not know? Discuss the significance of asking questions to become aware of the unknown.

• The purpose of assessing risk is to understand the risk component of decisions. When we identify and analyze risk, we assess the probability and consequence of unsatisfactory outcomes. Risk assessment is a method for discovery that informs us about the risk. We are better able to decide based on knowing the risk rather than not knowing it. We invest our experience in the attempt to understand the future. By measuring uncertainty, we are developing an awareness of the future. Future awareness is the result of a cognitive thinking process. When we are cognizant, we are fully informed and aware.

• More to the point if you don’t start asking questions about potential problems they may only come to light when it is impossible to fix them. In this case the project can fail. When you start asking questions you bring to light issues that may not be obvious because of the project you are currently undertaking.

2. Explain why the project manager is responsible for delegating the task of conducting a risk assessment.

• The project manager is responsible for delegating the task of conducting a risk assessment, which provides a baseline of assessed risks to the project. A risk baseline should be determined for a project as soon as possible so that risk is associated with the work, not with the people. By understanding the worst-case outcome, we bound our uncertainty and contain our fears. Risk assessment helps take some emotion out so we can deal with the project because individual knowledge is diverse. Conducting a risk assessment helps to train the risk assessment methods that will be used throughout the project.

3. List three types of risk assessment methods and describe a situation when each would be appropriate.

• Known risks are those that you are aware of. Communication helps you understand known risk in the following ways:

• a. Separate individuals from issues. Sometimes the right person knows about a risk but is afraid to communicate it to the team, fearing that the team will perceive the individual, not the issue, at risk. In one case, the person responsible for configuration management had no tool training but during the interview session did not raise this as a risk. Fortunately, somebody else raised this issue as a risk, so that it could be resolved.

• b. Report risks. The most frequently reported software development risks are issues often found on software projects. It is likely that other software projects report risks similar to those found on your project.

• c. Report problems. Everyone knows about issues that are pervasive within the organization, such as the lack of a software process. When there are problems without a focus for improvement, these problems are known future risks. If you have problems that are likely to worsen without proper attention, you should add them to the risk list.

4. Discuss the extent to which sharing information can discover unknown risks.

• Unknown risks are those that exist without anyone’s awareness of them. Communication helps discover unknown risk in the following ways:

• a. Share knowledge. A team can discover risks by individuals’ contributing what they know. The collective information forms a more complete picture of the risk in a situation. Individuals contribute pieces of a puzzle that they could not resolve on their own.

• b. Recognize importance. We sometimes identify risks without an awareness of their significance. Discovering the magnitude of the risk helps in prioritizing it correctly. The passing of time helps us to discover risk importance, but only if we are paying attention. When we are not paying attention, risk turns into problems, when it may be too late to repair the damage.

• c. Cumulate indicators. A status indication that is 10 percent off target is generally perceived as low risk. The summation of a small variance in several indicators can add up to a critical risk. Count the number of indicators exceeding threshold and discover the effect of aggregate risk.

5. List the five steps to categorize risk. What is the value of each step?

• Risk assessment results are often categorized to communicate the nature of a risk. There are five steps to categorize risk:

• 1. Clarify. Write the risk statement according to the standard notation. Describe the risk in its simplest terms to refine the understanding of the issue.

• 2. Consensus. Agree on the meaning of the risk statement. Once everyone understands the issue, you should agree on the scope of the issue as written. Agreement is not about the validity of the issue as a risk but about the meaning and intent of the issue as documented.

• 3. Classify. Select the risk category form a risk classification scheme, such as the SEI software risk taxonomy. If two or more categories describe the risk, the risk may be a compound one. Decompose risks to their lowest level. Note the dependencies that link related risks together.

• 4. Combine. Group risk statements by risk categories. Roll up all the issues in a category and review then to gain a general understanding of this category by the different perspective documented in the risks.

• 5. Condense. Remove duplicates and summarize related risks. After you summarize the issues in a logical area, you can easily locate and remove duplicates. Then group related risks with other risks by risk category.

6. Explain the risk drivers that might cause an SEI Level 3 process to degrade.

• Risk driver are the variables that cause either the probability or consequence to increase significantly – for example, constraints, resources, technology, and tools. The process and environment can also be risk drivers. These forces cause risk to change over time. For example, your SEI Level 3 process can be reduced to an ad hoc SEI Level 1 process over time due to the risk driver of schedule. You would want to specify the schedule constraint as the risk driver that causes the process to be at risk. Because risks are dynamic, it is important to specify the risk drivers to describe the factors that support risk occurrence. Understanding the risk drivers will help you know where to begin to resolve risk.

7. Do you think it is important to communicate risk in a standard format? Discuss how a standard format might make people more receptive to dealing with uncertainty.

• Communicate identified risk to appropriate project personnel to increase awareness of project issues in a timely manner. You can communicate identified risk by submitting the risk management form. Logging risks in a risk database is one mechanism to facilitate communication of identified risks. Risks that are logged into the system can be periodically reviewed. The “Risk Category” and “WBS Element” fields of the risk management form help to identify the appropriate project personnel who should review the risk.

• A risk management form for documenting the risk provides a familiar mechanism that structures how we think about risk.

8. Explain how you could measure risk exposure over time and predict risk occurrence.

• Once the risk is clearly communicated, an estimate of risk exposure – the product of risk probability and consequence – can be made. The estimate of risk exposure and the time frame for action help to establish a category of risk severity, which determines the relative risk priority by mapping categories of risk exposure against the time frame for action. An evaluation of risk severity in relation to other logged risks determines the actual risk priority. Criteria for risk evaluation should be established.

9. Discuss how you can use time frame for action to determine risk priority.

• Prioritizing risk provides a focus for what is really important. Your prioritized risk will be unique to your role on a specific project. In general, the challenges of managing software development can be understood by reviewing the current list of prioritized risks reported by the software community. Government and industry sectors of the software community have different yet interrelated risks. The government role is primarily that of acquirer (i.e., customer), while industry is the primary developer (i.e., producer). By understanding the risks of each sector, we can work better together as a software community. Through a partnership in helping each other, we ultimately help ourselves. The remainder of this section reflects on the risks most often reported from risks in the 1990s and how the list has changed from the 1980s.

10. Do you trust your intuition? Give an example of a time when you did and a time when you did not trust your intuition.

• Trusting your intuition is important. But in software development it can be a little deceiving. For example, I was asked to create a program that parses a computer generated log file. The log file was developed to be “human” readable and doesn’t lend itself to easy program parsing. I have had a lot of experience in file parsing and felt that it would be no problem. In this case I was correct and wrote the program with little trouble.

• On the other hand, I mostly develop database driven applications. I was tasked to write a simple database report so I thought this would be no problem. The platform I was using was ASP.Net and I was using a data set configured from the visual interface. I ran into a problem when my report had to refine itself based upon user input. I was having difficulty adjusting the parameters through the menu provided. I found that I had to create an individual dataset for each of the various sort options, which was very cumbersome. What I need was the ability to change the data set parameters through code. In the end the project changed platforms to classics ASP because of other difficulties we were having. One year later I discovered how to deal with data sets through code. I was not using the correct .Net terms, Typed and UnTyped. This proved to be a frustrating situation and something I didn’t anticipate happening.